Diagram 5 — Managed Firewall Service with CoSine's Network-based Solution 




POP Infrastructure 

The POP access infrastructure in the network-based managed firewall service model 
is based on the CoSine Communications IPSX 9000 Service Processing Switch. The 
base configuration for the switch includes: 

■ 26-slot chassis 

■ Redundant power supply 

■ IPNOS Base Software 

■ Ring Bridge & Ring Bridge Pass-Thru (to complete midplane) 

■ Control Blade (for communications with InVision Services Management System) 

■ Dual-port Channelized DS3 Access Blade 

■ Dual-port Unchannelized DS3 Access Blades 

■ Processor Blade 

■ OC-3c POS Trunk Blade 

The following tables analyze the cost structure of all of the above models and 
projects these costs out over 5 years: 
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I 2. OM Desigrr 



2.1. Overview 

The Object Manager consists of 3 layers as showp^n Figure 1. The upper layer titled OA 
Configuration Database (OMCD) is concfemed wifh managing the VPN and VR configuration. 
This is the agent that deals with CM directr^Aliddle layer titled is OM Object Routing and 
Interface Global concerned with managing > glorai s facross the IPSX system) object groups and 
object configurations. The lower layer titfed OMofyect Routing and Interface (OMORI) is y 
concerned with managing local objects/ and groups a$ well as routing control informal 
between address spaces based on the location of objects, and interfacing with the obiecivia 
sthod invocation. ^ 




Object Channels 



Object Channels 



Figure*/. Object Manager Layers 



- 2.1,1. Potdba s o d istribution 

IPSX object database consists of two types of database: Global, managed on Master Control 
Blade by OMORIG and distributed local databases, managed by OMORI agents on every PE 
present in the system. Global database is a superset of the extracts from local databases. 

2.2. Object 

Objects represent a basic unit of management for purposes of fault tolerance, computational load 
balancing etc. One or more adjacent protocol modules can be placed into a single object. It is 
also possible that a module is split across two objects. 
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IPSX Packet Processin|^lquirements 
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Application- 1 



Application-2 



Application-3 



Routing Protocols 




Sockets 
TCP/UDP/GRE 

IP Local (Output, Input Re-assembly, Protocol Demux, IPSec-in) 

IP Forwarding 
(Packet Filtering, Route Lookup, IPSec-out) 



IP Input 
(Packet Filtering, 
DeNAT) 



IP Output 
(Packet Filtering, 
NAT, IPSec-out) 





Figure^: Standard Protocol Stack Profile 

; We now look at wh^t would happen in IPNOS 1.x for typical application flows. The inter- 
module transfers are shown in Figure^. The processiprg sequence is 

1 ) Packet is received from the subscriber Hjre interface 

2) Processed by IP \wd module and parsed to IP Local module 

3) Demux'ed by IP Loc^l and passejaTon to the Application 
, 4) Application process data and sends transformed data 

| 5) IP Local sends packet to subscriber IP Fwd module 

! 6) Subscriber IP Fwd forw^s\to ISP IP Fwd module 

| 7) ISP IP Fwd module sends it to l§P line interface 

j Note that steps 2, 3, 4, 5, y require an int^r-PE transfer. Each of these steps may 
represent a backplane crossing. 
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IPSX Packet Processin^P&quirements 
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Figure^: Firewall flow processing 

2.3 Differentiating between L3 and L4 flows 

Figure 3 shows the contents that can be used to determine a L4 packet flow when the 
packet is unfragmented (determined by the corKlition (MF == 0 && Offset == 0)). It also 
shows the contents that can be usf d to det^miine a L3 packet flow when the packet is 
fragmented. 

be noted that the ID field is preserved across 
the receiver may receive the fragments in 
only use <Source, Destination, Protocol> to 
n not create per packet flow state which uses 
fragments on the false assumption that the 



When a packet gets fragmented, it srtpu. 
all fragments of the packet. Howev 
arbitrary order. Thus the receiver ntfa 
determine the packet flow. The receiver 
the ID field to decide on the L4 flew for a N 
first fragment contains L4 information 

NOTE: All fragmented Jackets must be reassembled before the L4 flow 
can be inferred. This>nas implications w L4 oriented services like NAT. 
For NAT to work /correctly, the gateway must reassemble every 
fragmented packet before it can perform its\packet transformation. This is 
a tremendous burden and many NAT implementations (including IPSX) 
simply do not transform the fragments subsequent to the first. 
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IPSX Packet Processinl^fequirements 
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Original Unfragmented IP Packet (MF~ 0 && OJf= 0) 



Src,Dest,Proto 
MF=0,Of£=0 
n>10AF ? Ien=1064 



Src Port 
Dest Port 



Data[0-1023] 



Fragmented IP Packet (each fragment is 534 bytes long) 



Src,Dest.Proto 
MF=l,Off=0 
ID=10AF, len=512 


Src Port 
Dest Port 


Data[0-471] 




Src,Dest,Proto 
MF=l,OfM92 
ID- 1 OAF, len=512 


Data[472-963] 




Src,DestProto 
MF=l,Off=984 
n>10AF, len=80 


Data[964-1023] 



IP Fragment 1 



IP Fragment 2 



IP Fragment 3 



Figure Packet Fragmentation and Header Content 
Issues and Solutions 



3.1 Issues to be addressed 

In this section we identify several specific flows that we wish to have optimized. The 
forward flows are shown as originating at a Subscriber interface and ending at an ISP 
interface in the upper half of Figure 4, Figure 5, Figure 6 and Figure 7. The reverse flow 
is shown in the lower half of each figure. 

The un-optimized flows are shown in black arrows and represent a fragment of the 
Configured Topology, The red arrows represent the optimized flows with shortcuts that 
we would like to generate and represent a fragment of the Flow Topology. 
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Figure fi\ Encryption flows 




Figure f\ Socket flows 
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Figure ,61 Distributed Forwarding 
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rjj Figure ft: MP-P Operation 

U 3.2.2 Replicator FIB H /] 

'% The IP Forwarding agent uses the Forwarding Information Base (FIB) to make its 

Y forwarding decision. WrWi the Virtual Router (VR) terminates links on multiple blades, 

? 3 the VR has to have multiple IP Forwarding agents. Thi£ requires the IP Forwarding 

3 agents to maintain a Replicated FIB. This feature has been referred to variously as 

11 Multi-FIB, Distributed FIB ano\Sp//f FIB ... none of whjcn reflects the actual operation. 

zi : The Replicated FIB need not Be constrained to onjy IP Forwarding agents within a VR. 
;i A Replicated FIB may be used by other objects ofa VR to make forwarding decisions to 
'r" support shortcuts. \ / 

It should be noted that there is a\ host other data structures that also need to be 
replicated. These are \ / 

1) Packet Filters (PF), both dynamic and static. 

2) Security Policy Database iSPD^and Security Association Database (SAD). 

3) Network Address Translation (NAT) tables. 



3.2.3 Distributed Protocol Stack (Flow BWd) 

IPNOS 1.1 supports a functionally distributed protocol stack, which strictly implements 
the Configured Topology/ Figure 2 shows the planned functional decomposition of the 
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